System and method for processing a payment transaction based on point-of-sale device and user device locations

ABSTRACT

A method for processing a payment transaction is provided that is based on device locations. The method includes a processor receiving a request to authorize an action from a point of sale (POS) device with the request including context representing a first location associated with the action and context representing information about an account associated with the action. In response to receiving additional context including a location associated with a user device from the user device, the processor compares the context representing the first location and the additional context to determine whether to authorize the action.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 15/805,889, entitled “SYSTEM AND METHOD FOR AUTHORIZING APAYMENT TRANSACTION BASED ON DEVICE LOCATIONS,” filed on Nov. 7, 2017,which is a continuation-in-part of U.S. patent application Ser. No.13/829,132, entitled “SYSTEM AND METHOD FOR AUTHORIZING A PAYMENTTRANSACTION, filed on Mar. 14, 2013, now U.S. Pat. No. 9,852,416, eachof which is incorporated by reference in its entirety. This applicationis related to: U.S. application Ser. No. 15/687,395, entitled “METHODSAND SYSTEMS FOR BLOCKING THE INSTALLATION OF AN APPLICATION TO IMPROVETHE FUNCTIONING OF A MOBILE COMMUNICATIONS DEVICE,” filed on Aug. 25,2017; U.S. application Ser. No. 15/608,556, entitled “METHODS ANDSYSTEMS FOR DETECTING AND PREVENTING NETWORK CONNECTION COMPROMISE,”filed on May 30, 2017; U.S. application Ser. No. 14/634,115, entitled“ASSESSING A SECURITY STATE OF A MOBILE COMMUNICATIONS DEVICE TODETERMINE ACCESS TO SPECIFIC TASKS,” filed on Feb. 27, 2015; and U.S.application Ser. No. 14/071,366, entitled “METHODS AND SYSTEMS FORSECURE NETWORK CONNECTIONS,” filed on Nov. 4, 2013, each of which isincorporated by reference in its entirety.

TECHNICAL FIELD

The present invention relates to the field of information technology,including, more particularly, to systems and techniques for authorizinga payment transaction based on a location of an authenticating device.

BACKGROUND OF THE INVENTION

Mobile electronic communication devices have evolved beyond simpletelephone functionality and are now highly complex multifunctionaldevices with capabilities rivaling those of desktop or laptop computers.In addition to voice communications, many mobile communication devicesare capable of text messaging, e-mail communications, internet access,and the ability to run full-featured application software. Mobilecommunication devices can use these capabilities to perform onlinetransactions such as banking, stock trading, payments, and otherfinancial activities. Furthermore, mobile communication devices used byan individual, a business, or a government agency often storeconfidential or private information in forms such as electronicdocuments, text messages, access codes, passwords, account numbers,e-mail addresses, personal communications, phone numbers, and financialinformation.

In addition to the functionality described above, mobile electroniccommunication devices are frequently being used to perform mobilepayments, thereby eliminating the need, in some cases, for customers tocarry coin/paper currency, checks or credit/debit cards. In a particularimplementation, a merchant or a service provider is equipped with apoint of sale (“POS”) module, e.g., an NFC reader, that is coupled to apayment processing system on a server or in a cloud computingenvironment. When a mobile communication device is configured for mobilepayments, a user of the device can purchase items from the merchant bysimply using the device to exchange a user's payment credentials fromthe device to the POS module. The credentials can be transmitted to thePOS module by tapping the configured mobile communication device on asensor of the POS module, or by waving the device near the POS module'ssensor. The payment amount can be deducted from a pre-paid account orcharged to a mobile or bank account directly.

As mobile payments using phone-based or electronic wallet-based paymentsmediated by the use of mobile devices become more widespread, it is morelikely that there will be attempts to steal user payment credentials andto use them fraudulently. This could be done by malware on a user'scommunication device or personal computer, or by network eavesdroppingon a user's network connections, for example. Accordingly, a merchant, apayment processor, and/or the user herself need to be sure that whenmobile payment credentials are presented at a POS module, the personpresenting them is actually the user associated with the paymentcredentials or is someone who has stolen the payment credentials to makeunauthorized purchases.

DESCRIPTION OF THE FIGURES

In the following drawings like reference numbers are used to refer tolike elements. Although the following figures depict various examples,the one or more implementations are not limited to the examples depictedin the figures.

FIG. 1 is a block diagram illustrating a system including an electronicdevice and a server coupled to a network according to an embodiment;

FIG. 2 is a block diagram illustrating of a specific implementation of asystem of the invention according to an embodiment;

FIG. 3 is an operational flow diagram illustrating a high level overviewof a method of the invention according to an embodiment;

FIG. 4 is a block diagram illustrating an alternative implementation ofa system of the invention according to an embodiment;

FIG. 5 is an operational flow diagram illustrating a high level overviewof a method of the invention according to another embodiment; and

FIG. 6 is an operational flow diagram illustrating a high level overviewof a method of the invention according to an embodiment.

DETAILED DESCRIPTION

It should be appreciated that the present invention can be implementedin numerous ways, including as a process, an apparatus, a system, adevice, a method, or a computer readable medium such as a computerreadable storage medium containing computer readable instructions orcomputer program code, or a computer network wherein computer readableinstructions or computer program code are sent over optical orelectronic communication links. Applications, software programs orcomputer readable instructions may be referred to as components ormodules. Applications may take the form of software executing on ageneral purpose computer or be hardwired or hard coded in hardware.Applications may also be downloaded in whole or in part through the useof a software development kit, framework, or toolkit that enables thecreation and implementation of the present invention. In thisspecification, these implementations, or any other form that theinvention may take, may be referred to as techniques. In general, theorder of the steps of disclosed processes may be altered within thescope of the invention.

According to an embodiment, an authorizing client device is associatedwith a user and is typically located on or near the user. Thus, thelocation of the authorizing client device is indicative of the user'slocation. Based on this assumption, when a mobile payment transaction ofthe user is initiated on a POS module, the location of the user'sauthorizing client device can be used to determine whether the paymenttransaction is legitimate, e.g., being initiated by the user, orfraudulent, e.g., being initiated by a person other than the user.

In an embodiment, a system for authorizing a mobile payment transactionincludes an anti-fraud service coupled to the payment processing systemthat interfaces with the POS module. When a payment transaction isinitiated at the POS module, the anti-fraud service can receive arequest to authorize the payment transaction. The request can includepayment information of the payment transaction and informationidentifying the POS module, which can include or be used to identify thePOS's location. When the request is received, the anti-fraud service canidentify an authorizing client device based on the payment informationand then can determine location information of the authorizing clientdevice. Once the location information of the authorizing client deviceand of the POS module are determined, the anti-fraud service can comparethe location information to determine a disposition of the request toauthorize the payment transaction.

According to an embodiment, when the location of the user's authorizingclient device is at or near the POS module, the user associated with thepresented payment information is presumably also at or near the POSmodule, and payment authorization can be granted. Otherwise, when theopposite is true, i.e., the authorizing client device's location is notin proximity to the POS module, the payment authorization can be deniedor additional authentication information can be requested from thecustomer. In an embodiment, the authorizing client device can be adedicated device. In another embodiment, the authorizing client devicecan be a personal electronic device associated with the user, e.g., asmart phone, a car fob, or any other personal item typically carried bythe user.

As used herein, the term “mobile communication device” refers to mobilephones, tablets, PDAs and smartphones. The term “mobile communicationsdevice” also refers to a class of laptop computers which run anoperating system that is also used on mobile phones, tablets, PDAs, orsmartphones. Such laptop computers are often designed to operate with acontinuous connection to a cellular network or to the internet via awireless link. Specifically, mobile communication devices includedevices for which wireless communication services such as voice,messaging, data, or other wireless Internet capabilities are a primaryfunction. As used herein, a “mobile communication device” may also bereferred to as an “electronic device,” an “electronic client device,”“mobile device,” “mobile client,” or “handset.” However, a person havingskill in the art will appreciate that while the present invention isdisclosed herein as being used on mobile communication devices, thepresent invention may also be used on other computing platforms,including desktop, laptop, notebook, netbook, or server computers.

Prior to describing the subject matter in detail, an exemplary networkin which the subject matter may be implemented shall first be described.Those of ordinary skill in the art will appreciate that the elementsillustrated in FIG. 1 may vary depending on the system implementation.FIG. 1 is a simplified block diagram of a computer network 100 thatincludes a mobile communication device 101, a server system 111, a POSmodule 112 and other electronic client devices 140 a-140 c, coupled to acommunication network 121 via a plurality of communication links 130.Communication network 121 may be comprised of many interconnectedcomputer systems and communication links. Communication links 130 may behardwire links, optical links, satellite or other wirelesscommunications links, wave propagation links, or any other mechanismsfor communication of information. Various communication protocols may beused to facilitate communication between the various devices shown inFIG. 1. These communication protocols may include TCP/IP, HTTPprotocols, wireless application protocol (WAP), vendor-specificprotocols, customized protocols, Internet telephony, IP telephony,digital voice, voice over broadband (VoBB), broadband telephony, Voiceover IP (VoIP), public switched telephone network (PSTN), and others.While in one embodiment, communication network 112 can be the Internet,in other embodiments, communication network 112 may be any suitablecommunication network including a local area network (LAN), a wide areanetwork (WAN), a wireless network, a intranet, a private network, apublic network, a switched network, and combinations of these, and thelike.

In an embodiment, the mobile device 101 includes: an operating system113, an input device 115, a radio frequency transceiver(s) 116, a visualdisplay 125, and a battery or power supply 119. Each of these componentsis coupled to a central processing unit (CPU) 103. The device operatingsystem 113 runs on the CPU 103 and enables interaction betweenapplication programs and the mobile device hardware components. In anembodiment, the mobile device 101 receives data through an RFtransceiver(s) 116 which may be able to communicate via variousnetworks, for example: BLUETOOTH, local area networks such as WI-FI, andcellular networks such as GSM, CDMA or LTE.

In an embodiment, a local software component 175 is an applicationprogram that is downloaded to a mobile device and installed so that itintegrates with the operating system 113. Much of the source code forthe local software component 175 can be re-used between various mobiledevice platforms by using a cross-platform software architecture. Insuch a system, the majority of software functionality can be implementedin a cross-platform core module. The cross-platform core can beuniversal allowing it to interface with various mobile device operatingsystems by using a platform-specific module and a platform abstractionmodule that both interact with the mobile device operating system 113,which is described in U.S. Pat. No. 8,099,472, entitled “SYSTEM ANDMETHOD FOR A MOBILE CROSS-PLATFORM SOFTWARE SYSTEM.” In anotherembodiment, the local software component 175 can be device, platform oroperating system specific.

As indicated above, the mobile device 101 may operate in a networkedenvironment using logical connections 130 to one or more remote nodes111, 112, 140 a-140 c via a communication interface. The remote node maybe another computer 140 a, a server 111, an NFC reader/POS module 112, aclient device 140 b-140 c or other common network node, and typicallyincludes many or all of the elements described above relative to themobile device 101. The communication interface may interface with awireless network and/or a wired network. Examples of wireless networksinclude, for example, a BLUETOOTH network, a wireless personal areanetwork, a wireless 802.11 local area network (LAN), a near fieldcommunication (NFC), and/or wireless telephony network (e.g., acellular, PCS, or GSM network). Examples of wired networks include, forexample, a LAN, a fiber optic network, a wired personal area network, atelephony network, and/or a wide area network (WAN). Such networkingenvironments are commonplace in intranets, the Internet, offices,enterprise-wide computer networks and the like.

It should be understood that the arrangement of mobile communicationdevice 101 illustrated in FIG. 1 is but one possible implementation andthat other arrangements are possible. It should also be understood thatthe various system components (and means) defined by the claims,described below, and illustrated in the various block diagrams representlogical components that are configured to perform the functionalitydescribed herein. For example, one or more of these system components(and means) can be realized, in whole or in part, by at least some ofthe components illustrated in the arrangement of mobile device 101. Inaddition, while at least one of these components are implemented atleast partially as an electronic hardware component, and thereforeconstitutes a machine, the other components may be implemented insoftware, hardware, or a combination of software and hardware. Moreparticularly, at least one component defined by the claims isimplemented at least partially as an electronic hardware component, suchas an instruction execution machine (e.g., a processor-based orprocessor-containing machine) and/or as specialized circuits orcircuitry (e.g., discrete logic gates interconnected to perform aspecialized function), such as those illustrated in FIG. 1. Othercomponents may be implemented in software, hardware, or a combination ofsoftware and hardware. Moreover, some or all of these other componentsmay be combined, some may be omitted altogether, and additionalcomponents can be added while still achieving the functionalitydescribed herein. Thus, the subject matter described herein can beembodied in many different variations, and all such variations arecontemplated to be within the scope of what is claimed.

In the description that follows, the subject matter will be describedwith reference to acts and symbolic representations of operations thatare performed by one or more devices, unless indicated otherwise. Assuch, it will be understood that such acts and operations, which are attimes referred to as being computer-executed, include the manipulationby the processing unit of data in a structured form. This manipulationtransforms the data or maintains it at locations in the memory system ofthe device, which reconfigures or otherwise alters the operation of thedevice in a manner well understood by those skilled in the art. The datastructures where data is maintained are physical locations of the memorythat have particular properties defined by the format of the data.However, while the subject matter is being described in the foregoingcontext, it is not meant to be limiting as those of skill in the artwill appreciate that various of the acts and operation describedhereinafter may also be implemented in hardware.

FIG. 2 is a block diagram illustrating a system for authorizing a mobilepayment transaction according to an embodiment. As is shown in FIG. 2,the system 200 includes a payment facilitating device 210, a POS module220, and a payment processing server 230 communicatively coupled to oneanother over one or more communication networks 201. The paymentfacilitating device 210 can be the client device used to initiate apayment transaction via the POS module 220 and can be a mobilecommunication device 101, or any one of the other electronic clientsystems 140 a-140 c. Accordingly, the payment facilitating device 210can include a display screen 216 and an operating system (not shown)that supports various device features and/or applications, such as amobile payment application 212. The device 210 can be a portableelectronic device that can be easily carried in a customer's pocket,wallet, purse or other personal item. In an embodiment, the device 210can be a dedicated stand-alone device such as a card or a key chain.Alternatively, it can be integrated with another portable electronicclient device associated with the customer 206, e.g., the customer'ssmart phone, car fob, or any other personal item typically carried bythe customer.

The POS module 220 can be an in-store NFC reader and/or a BLUETOOTHenabled device that is configured to receive the user's paymentcredentials 202 for the payment transaction from the paymentfacilitating device 210. In an embodiment, for example, when the paymentfacilitating device 210 is positioned near a sensor (not shown) in thePOS module 220 or is physically tapped against the sensor, thecustomer's payment credentials 202 can be transmitted to the POS module220. According to an embodiment, the POS module 220 collects paymentinformation 222 for the payment transaction that can include thecustomer's payment credentials 202 and information identifying thecustomer 206. The payment information 222 can then be transmitted fromthe POS module 220 to the payment processing server 230 in a request toprocess the payment 203.

The payment processing server 230 hosts a payment processing service 240that stores user information 242 that can include informationidentifying the user 207, a user's credit/debit card information and/orbanking information so that mobile payment transactions can be processedfor the user's purchases. The payment processing service 240 can receivethe request to process the payment transaction 203 and can use theincluded payment credentials 202 of the customer 206/user 207 toretrieve the user information 242 associated with the user 207. Theamount of the payment transaction can then be deducted from or chargedto the user's banking/credit account. When the payment transaction iscompleted, the payment processing service 240 can generate a response203 a to the request to process that indicates that the paymenttransaction was successfully processed and can transmit the response 203a to the POS module 220. When the response 203 a is received, the POSmodule 220 can provide a receipt to the customer 206 or provide someother indication that the payment transaction has been successfullycompleted, e.g., by providing a message on a display 226.

Presumably, the customer 206 and the user 207 are the same entity andpresumably, the submitted payment credentials 202 are associated withthe customer 206/user 207. Nonetheless, such an assumption may beerroneous if the payment credentials 202 have been stolen by thecustomer 206 and embedded into the mobile payment application 212 of thefacilitating device 210. In this case, the customer 206 can effectivelyimpersonate the user 207 and use the user's payment credentials 202 toimproperly procure items and/or services, which will be charged to theuser 207.

To address this issue, a system and method is described for authorizinga mobile payment transaction based on the proximity of an authorizingclient device associated with the user 207 to the POS module 220.According to an embodiment, the authorizing client device can be adevice that is typically on or near the user 207 so that a location ofthe authorizing client device is indicative of a location of the user207. Thus, when the authorizing client device's location is at or near alocation of the POS module 220, it is highly likely that the customer206 and the user 207 are the same entity and that the paymenttransaction is legitimate. When the opposite is true, there is a strongsuggestion that the payment transaction is fraudulent.

FIG. 3 is a flow diagram illustrating a method for authorizing a mobilepayment transaction according to an embodiment. The method illustratedin FIG. 3 can be carried out by at least some of the components in theexample electronic device(s) illustrated in FIG. 1 and FIG. 2, but canalso be carried out in environments other than those illustrated in FIG.1 and FIG. 2. According to an embodiment, the method 300 begins, inblock 302, when a request to authorize a payment transaction thatoriginates from a POS module is received. In an embodiment, a system forauthorizing a mobile payment transaction includes an anti-fraud service250 configured for receiving the request to authorize the paymenttransaction 204. According to an embodiment, the anti-fraud service 250can receive the request 204 from the payment processing service 240 whenit receives the request to process the payment transaction 203 from thePOS module 220.

The anti-fraud service 250 can be hosted by the payment processingserver 230 as is shown in FIG. 2. Alternatively, in another embodimentshown in FIG. 4, the anti-fraud service 450 can reside in another server432 communicatively coupled to the payment processing server 430 and/orto the POS module 420 over the network 401. In this embodiment, theanti-fraud service 450 can receive the request 404 over the network 401from the POS module 420 when the POS module 420 receives the paymentcredentials 402 from the facilitating mobile device 410. In anotherembodiment, the payment processing service 240, 440 and/or theanti-fraud service 250, 450 can be integrated in a common device withthe POS module 220, 420. In this case, the anti-fraud service 250, 450can receive the request to authorize 204, 404 via an internal link fromeither the payment processing service 240, 440 or the POS module 220,420.

In an embodiment, the request to authorize the payment transaction 204,404 can include the payment information 222, 422 of the paymenttransaction and information identifying the POS module 224, 424. Asstated above, the payment information 222 can include the paymentcredentials, e.g., 202, and information identifying the user 207 withwhich the payment credentials are associated. The informationidentifying the POS, e.g., 424, can include location information of thePOS module 424 a and/or information that can be used to determine thelocation information of the POS module 220, 420. For example, the POSidentifying information, e.g., 224, can include an identifier that canbe correlated to a location of the POS module 220. This correlation canbe included in a table that associates POS identifiers with locationsfor a plurality of POS modules, and the table can be stored in adatabase (not shown) on the payment processing server 230 or elsewhereon another server accessible via the network 201.

Referring again to FIG. 3, when the request to authorize the paymenttransaction 204, 404 is received by the anti-fraud service component(250, 450), an authorizing client device for the payment transaction isidentified based on the payment information 222, 422 in block 304.According to an embodiment, the authorizing client device, e.g., 210 a,is a personal mobile device associated with a user 207 that includes amobile payment application 212 a, and an anti-fraud client application214 which allows the anti-fraud service 250 to communicate with theauthorizing client device 210 a over the network 201. In an embodiment,for example, the authorizing client device 210 a can be a smartphone, atablet computer, or any network enabled handheld personal device.

In an embodiment, during a service registration phase, a user 207 candesignate one or more of her personal network enabled client devices tobe an authorizing client device 210 a for the user's mobile paymenttransactions. The user 207 can provide information relating to theclient device 210 a that enables the anti-fraud service 250 tocommunicate with the client device 210 a. For example, when theauthorizing client device 210 a is the user's mobile phone, the phonenumber associated with the phone can be provided. In another embodiment,the authorizing client device 210 a can be a dedicated client devicethat is provided to the user 207 upon registering with a serviceprovider associated with the anti-fraud service.

According to an embodiment, the anti-fraud service component 250, 450can store the information relating to the user's authorizing clientdevice(s) 252, 452 in a storage component coupled to the server 230, 432and accessed by the anti-fraud service component 250, 450. In anembodiment, when the request to authorize the payment transaction 204,404 is received, the anti-fraud service 250, 450 can be configured toextract the payment credentials 202, 402 of the user 207 from thepayment information 222, 422, in order to identify the user 207. Oncethe user 207 is identified, the anti-fraud service 250, 450 can beconfigured, in an embodiment, to identify the user's authorizing clientdevice 210 a by retrieving the information 252, 452 relating to theuser's authorizing client device(s).

Referring again to FIG. 3, once the authorizing client device for thepayment transaction, e.g., 210 a, is identified, the anti-fraud service250 is configured to determine location information of the authorizingclient device 210 a in block 306. As noted above, the information 252relating to the user's authorizing client device 210 a includesinformation that enables the anti-fraud service 250 to communicate withthe client device 210 a. Therefore, according to an embodiment, theanti-fraud service, e.g., 250, can use the information 252 to generateand transmit a request for location information 205 to the authorizingclient device 210 a over the network 201, which in an embodiment, can bea Wi-Fi network, a LAN, a PAN, a WAN, a BLUETOOTH network, or a nearfield communication (NFC) depending on the circumstances. In anotherembodiment when the authorizing client device 210 a is a phone connectedto a cellular network, the request message 205 can be transmitted overthe cellular network 201.

In another embodiment, the anti-fraud service 250 can transmit therequest for location information 205′ to the authorizing client device210 a indirectly via the POS module 220. In this case, when the POSmodule 220 receives the request 205′, it can be configured to forwardthe request 205′ to the authorizing client device 210 a over the network201, which in this embodiment, can be a wireless short range personalarea network (“WPAN”), such as a BLUETOOTH network or a NFC network.

When the request for location 205 is received by the authorizing clientdevice 210 a, the anti-fraud client application 214 in the client device210 a can provide its location information in several ways. For example,in an embodiment, when the client device 210 a is equipped with a GlobalPositioning System (“GPS”) tracking unit, the device's locationinformation can be provided as geo-coordinates associated with itslocation. Alternatively or in addition, when the client device 210 a isconnected to a cellular network that includes a plurality of celltowers, the device's location information can also be provided as thelocation of a cell tower nearest to the authorizing client device 210 a.For example, the nearest cell tower can be the destination tower thattransmits the request message 205 directly to the authorizing clientdevice 210 a. Alternatively or in addition, when the client device 210 ais connected to a wired or wireless network 201, the locationinformation can be related to a wireless access point of the wirelessnetwork or related to a LAN.

According to an embodiment, the anti-fraud client application 214 in theclient device 210 a can be configured to generate a response 205 a tothe request for location 205 and to include the device's locationinformation in the response 205 a. The response 205 a can then bereturned to and received by the anti-fraud service 250 over the network201. In an embodiment, the anti-fraud service 250 can receive theresponse 205 a directly from the client device 210 a over the network201, while in another embodiment, the anti-fraud service 250 can receivethe response 250 a′ indirectly via the POS module 220. In the lattercase, the response 205 a′ may not be received by the POS module 220 whenthe authorizing client device 210 a is not located within the module'sshort range WPAN 201. If, however, the client device 210 a is locatedwithin the short range WPAN 201, the POS module 220 can be configured toreceive and forward the response 205′ to the anti-fraud service 250 overthe network 201.

As discussed above, the anti-fraud service 250 can be configured totransmit the request for location 205, 205′ to the authorizing clientdevice 210 a over different network environments, e.g., a WAN and aWPAN. The response 205 a, 250 a′ from the authorizing client device 210a can be received over the same network environment as the one used totransmit the request or over a different network environment from thatused to transmit the request. Accordingly, in an embodiment, theanti-fraud service 250 can transmit the request 205 to the client device210 a directly over a WAN, such as the Internet, and the response 205 a′can be received indirectly via the POS module 220 over a BLUETOOTHnetwork and a WAN.

Referring again to FIG. 3, when the location information of theauthorizing client device is determined, the anti-fraud service 250, 450can be configured to compare the location information of the authorizingclient device 210 a, 410 to the location information of the POS module220, 420 to determine a disposition of the request to authorize thepayment transaction in block 308. According to an embodiment, thedisposition of the request, i.e., whether the request 204, 404 isgranted, denied, or pending, can be determined based on whether and towhat degree the location of the authorizing client device 210 a, 410 isdifferent from the location of the POS module 220, 420.

For example, in FIG. 2, because the authorizing client device 210 a isnot the payment facilitating client device 210, there is a likelihoodthat the authorizing client device 210 a will be in a different locationfrom the POS module 220, and that therefore the location information ofthe client device 210 a will be different from that of the POS module220. Alternatively, in FIG. 4, because the authorizing client device 410is the payment facilitating device, it is likely that the locationinformation of the authorizing client device 410 is substantially thesame as the location information of the POS module 420.

Depending on the circumstances, when the location information of theauthorizing client device 210 a, 410 is different from the locationinformation of the POS module 220, 420, the anti-fraud service 250, 450can be configured to deny the request to authorize the paymenttransaction in an embodiment. In another embodiment, when the locationinformation of the authorizing client device corresponds to a firstgeo-location and the location information of the POS module correspondsto a second geo-location, the anti-fraud service 250, 450 can beconfigured to deny the request to authorize the payment transaction whena distance between the first geo-location and the second geo-locationexceeds a threshold distance. According to an embodiment, the thresholddistance can be provided by the user 207, 407 and/or by anadministrator, and can vary according to contextual circumstances. Forexample, a threshold distance for a POS module 220 located in a highlyrestricted area can be shorter/smaller than the threshold distance for aPOS module 420 in a public store because the adverse consequences ofallowing an unauthorized transaction in the highly restricted area canbe more severe than those in the public store.

According to an embodiment, the disposition of the request to authorize204, 404 can also depend on other circumstances unrelated to proximity.In an embodiment, a plurality of payment rules 454 can be provided thatdefine under what circumstances the request to authorize 404 should begranted or denied based on factors in addition to the authorizing clientdevice's proximity to the POS module 420. For example, a payment rule454 can be based on the location of the POS module 420 and can definewhether the request to authorize 404 should be granted, denied, orconditionally granted when the POS module's location is within aspecified region or location. So, for instance, such a location-basedpayment rule 454 can indicate that a request to authorize 404 should bedenied when the POS module 420 is located in a specified locationassociated with a particular fast food restaurant. Thus, even though theauthorizing client device's location is within a specified distance ofthe POS module's location, the request to authorize 404 will be deniedwhen the POS module's location is in the fast food restaurant.

In another embodiment, a payment rule 454 can be based on a temporalattribute of the payment transaction that defines the disposition of therequest to authorize 404 according to when the request to authorize 404is received. For example, such a time-based payment rule 454 canindicate that a request to authorize 404 should be granted duringspecified hours, specified days of the week, specified months, or duringa specified time interval. In an embodiment, because the payment rules454 are based on different factors, they can be enforced independentlyand simultaneously. Thus, the time-based payment rule 454 can beenforced along with the location-based payment rule 454.

In another embodiment, a payment rule 454 can be based on a type of itemand/or service associated with the payment transaction. For example,this type of payment rule 454 can provide a white or black list of itemsand services that are allowed or disallowed or disallowed unlessadditional authentication information is provided respectively. Similarto the other payment rules 454 described above, the item/service-basedpayment rules 454 can be enforced independently and simultaneously.

In addition, payment rules 454 can be based on a payment amountassociated with the payment transaction. According to an embodiment,transaction amount-based payment rules 454 can define the disposition ofthe request to authorize 404 according to the cost of any individuallycharge item and/or the total cost associated with the paymenttransaction. For example, the cost-based payment rules 454 can indicatethat a request to authorize 404 should be denied outright orconditionally denied unless additional authentication is provided when acost of an individual item exceeds a threshold value, and/or when thetotal cost of the transaction exceeds another threshold value. Inanother embodiment, the request to authorize 404 can be denied orconditionally denied when a frequency of payment transactions within aspecified time period exceeds another threshold value.

According to an embodiment, the payment rules 454 for the authorizingclient device 410 can be defined and provided by the user 407 associatedwith the client device 410. In an embodiment, some payment rules 454 canbe provided and stored during the registration phase along with theinformation relating to the authorizing client device 410. Alternativelyor in addition, other payment rules 454 can be stored on the authorizingclient device 410 and provided to the anti-fraud service component 450when the payment transaction is initiated or pending. Accordingly, theanti-fraud service component 450 can be configured to determine thedisposition of the request to authorize the payment transaction 404based on whether the authorizing client device 410 is located within apredetermined proximity to the POS module 420 and on whether at leastone of the payment rules 454 is satisfied.

As noted above, instead of or in addition to, denying the request, theanti-fraud service 250, 450 can be configured to conditionally deny therequest unless additional authentication information is provided by thecustomer 206/user 407. For example, in an embodiment, when theanti-fraud service 250, 450 would otherwise deny the request, it can beconfigured instead to transmit an indication to the POS module 220, 420directing it to request additional authentication information from thecustomer 206/user 407. For example, the customer 206 can be requested toproduce additional forms of identification or to submit a PIN orpassword to prove that she is the user 207, 407 associated with thepayment credentials 202.

In addition to denying the request and/or requesting additionalauthentication information, in another embodiment, the anti-fraudservice 250, 450 can be configured to send a message relating to therequested payment transaction at the POS module 220 to the authorizingclient device 210 a for display to the user 207 on the device's display216 a. According to an embodiment, the message can include a request toverify the requested payment transaction thereby allowing the user 207to override the anti-fraud service's denial and to indicate that thepayment transaction is legitimate. For example, when the customer 206 isan employee of the user 207 and is making a purchase on behalf of theuser 207, the user 207 can verify that the mobile payment transaction asan approved transaction. When the user 207 authorizes the requestedpayment transaction, the authorization can be included in a response tothe request to verify, which can be transmitted to and received by theanti-fraud service 250. Upon receipt, the anti-fraud service 250 can beconfigured to disregard the denial and to grant the request to authorizethe payment transaction.

In the embodiment described above, the anti-fraud service component 250is configured to proactively determine the location information of theauthorizing client device 210 a so that the location information of theauthorizing client device can be compared to that of the POS module 220.In another embodiment, the authorizing client device 410 can take a moreproactive role in providing its information automatically, and theanti-fraud service component 450 can take a more passive role bylistening for the information regarding the authorizing client device410. FIG. 5 is a flow diagram illustrating a method for authorizing amobile payment transaction according to this embodiment. The methodillustrated in FIG. 5 can be carried out by at least some of thecomponents in the example electronic device(s) illustrated in FIG. 1 andFIG. 4, but can also be carried out in environments other than thoseillustrated in FIG. 1 and FIG. 4.

According to an embodiment, the method 500 begins, in block 502, whenthe anti-fraud service component 450 receives the request to authorize apayment transaction 404 that originates from the POS module 420. Asdescribed above, the request to authorize 404 can be received from thePOS module 420 when the POS module 420 receives the payment credentials402 from the mobile device 410. Alternatively, it can be received fromthe payment processing service 440 when it receives the request toprocess the payment transaction 403 from the POS module 420. In eitherof these embodiments, the request 404 can be received over at least oneexternal network 401. In another embodiment, when the payment processingservice 440 and/or the anti-fraud service 450 are integrated in a commondevice with the POS module 420, the anti-fraud service 450 can receivethe request to authorize 404 via an internal link from either thepayment processing service 440 or the POS module 420.

Once the request to authorize the payment transaction 404 is received,the anti-fraud service 450 can be configured to determine whetherinformation regarding an authorizing client device for the paymenttransaction has been received in block 504 and to determine adisposition of the request when the information has been received inblock 506.

According to an embodiment, the anti-fraud client application 414 in theauthorizing client device 410 can be configured to collect informationregarding itself and to transmit that information 405 to the anti-fraudservice component 450 periodically and/or spontaneously. For example,the anti-fraud client application 414 can be configured to transmit theinformation regarding itself 405 every five (5) minutes. In anotherembodiment, the anti-fraud client application 414 can be configured totransmit the information 405 when the payment application 412 is invokedand/or when the payment credentials 402 of the user 407 are presented tothe POS module 420. Accordingly, the anti-fraud service component 450can receive the information regarding the authorizing client device 405periodically or when the client device 410 is used to facilitate apayment transaction.

In an embodiment, the information regarding the authorizing clientdevice 405 can include information identifying the client device and itslocation information. The anti-fraud service component 450 can beconfigured to receive the information, to identify the authorizingclient device 410 based on the received information, and to store thereceived information in the storage component along with the informationrelating to the user's authorizing client device(s) 452.

According to an embodiment, when the request to authorize 404 isreceived, the anti-fraud service component 450 can identify theauthorizing client device 410 for the payment transaction and candetermine that information regarding the identified authorizing clientdevice 405 has been received. In an embodiment, the anti-fraud servicecomponent 450 can be configured to compare the location information ofthe authorizing client device 410 to the location information of the POSmodule 424 a. In an embodiment where the information 405 is receivedperiodically, the client device's location information receivedimmediately prior to receiving the request to authorize 404 can becompared to the POS module's location information 424 a. The anti-fraudservice component 450 can be configured to grant the request toauthorize the payment transaction when the comparison indicates that theauthorizing client device 410 is located within a predetermined distanceof the POS module 420.

In another embodiment where the client device 410 automaticallytransmits the information 405 when the payment transaction is initiatedor while the payment transaction is pending, the fact that theinformation regarding the authorizing client device 405 is not receivedby the anti-fraud service component 450 suggests that the paymenttransaction is fraudulent. Thus, when the information regarding theauthorizing client device 405 has not been received under thesecircumstances, the anti-fraud service component 450 can be configured todeny the request to authorize the payment transaction.

In another embodiment, as described above with regard to FIG. 2, theanti-fraud service component 250 can be configured to transmit a request205, 205′ for the client device information, e.g., the locationinformation of the authorizing client device, to the client device 210 adirectly over the network 201 or indirectly via the POS module 220. Whenthe request 205 is received directly over the network 201, theanti-fraud client application 214 cannot transmit its response 205 a′ tothe anti-fraud service component 250 via the POS module 220 unless theclient device 210 a located within the module's wireless short rangenetwork. Alternatively, the anti-fraud service component 250 cannottransmit the request 205′ to the anti-fraud client application 214indirectly via the POS module 220 unless the client device 210 a islocated within the module's wireless short range network.

Accordingly, in this embodiment, the anti-fraud service component 250will receive the information 405 regarding the authorizing client devicewhen the client device 210 a, 410 is located within the POS module'swireless short range network. In this case, when the information 405regarding the authorizing client device has been received, theanti-fraud service component 450 can be configured to grant the requestto authorize the payment transaction 404. Alternatively, when the clientdevice 210 a, 410 is not located within the POS module's wireless shortrange network, the information 405 will not be received. In this case,when the information 405 regarding the authorizing client device has notbeen received, the anti-fraud service component 450 can be configured todeny the request to authorize the payment transaction 404.

According to yet another embodiment, instead of transmitting a requestfor location information 205 to the authorizing client device 210 a orwaiting to receive information 405 regarding the authorizing clientdevice 410, the anti-fraud service component 250, 450 can be configuredto transmit the location information of the POS module 424 a to theauthorizing client device 410, and to request that the authorizingclient device 410 confirm or deny that a current location of theauthorizing client device substantially matches the POS module'slocation information 424 a. In this embodiment, the anti-fraud clientapplication 414 in the client device 410 can be configured to receivethe location information of the POS module 424 a and the request, and tocompare its own location information to that of the POS module 420.

Based on the comparison, the anti-fraud client application 414 cangenerate a decision either confirming or denying that its currentlocation information substantially matches the POS module's locationinformation 424 a. The anti-fraud client application 414 can theninclude the decision in a reply message and can transmit the replymessage to the anti-fraud service component 450. Upon receiving thereply, the anti-fraud service component 450 can be configured todetermine the disposition of the request to authorize the paymenttransaction 404 based on the authorizing client device's decisionconfirming or denying that the current location information of theauthorizing client device substantially matches the POS module'slocation information 424 a. For example, when the decision isconfirming, the anti-fraud service component 450 can be configured togrant the request to authorize the payment transaction 404.

In an embodiment, the anti-fraud service 250, 450 can be configured togenerate a response 204 a, 404 a to the request to authorize 204, 404that includes the disposition of the request and to transmit theresponse to 204 a, 404 a to the payment processing service 240, 340and/or the POS module 220, 420. In an embodiment when the response 204 ais transmitted to the payment processing service 240, depending on thedisposition of the request, the payment processing service 240 caneither proceed with or stop processing the payment transaction. Inanother embodiment, when the response 404 a is transmitted to the POSmodule 420, the POS module 420 can transmit the request 203 to processthe payment transaction or deny the transaction depending on thedisposition.

According to embodiments, a system for authorizing a mobile paymenttransaction that originates from a POS module includes an anti-fraudservice component coupled to the POS module and/or to a paymentprocessing service associated with the POS module. In an embodiment,when payment credentials associated with a user are provided to the POSmodule to initiate the payment transaction, the anti-fraud servicecomponent can identify and determine a location a client devicetypically carried by the user. Because the user typically carries theclient device on his or her person, the device's location is indicativeof the user's location. In an embodiment, when the anti-fraud servicecomponent determines that the user's client device is located at or nearthe POS module, the payment transaction can be authorized based on theassumption that the authorized user is carrying the client device and isalso located at or near the POS module. When the location of the clientdevice is not at or near the POS module, the authorized user ispresumptively not at or near the POS module. In this case, the paymenttransaction can be denied outright or denied pending the presentation ofadditional authentication information from the customer.

According to an embodiment, the user may designate more than one of herpersonal network enabled client devices to be an authorizing clientdevice 210 a for the user's mobile payment transactions. The personalnetwork enabled client devices can be in different locations, buttypically only those devices that are actively in use will be consideredin the same location as the user. That is, it would be unusual for oneof the personal network enabled client devices to be actively in use atone location while one or more of the user's other personal networkenabled client devices are actively in use at a different location.

In an embodiment, based on this premise, the anti-fraud servicecomponent may obtain current locations for a plurality of authorizingclient devices, together with information indicating whether the devicesare actively in use. If one of the authorizing client devices is at thelocation of the POS module, and the other authorizing client devices arenot, but they are not currently active, then the transaction can bepermitted. Alternatively, if one or more of the authorizing clientdevices are not at the location of the POS module and are actively inuse, even if one of them is at the location of the POS module, thelegitimacy of the transaction can be questionable. In this embodiment,under such a situation, the anti-fraud service component can deny therequest to authorize the transaction, and/or request additionalauthentication or authorization information from the user via one ormore of the authorizing client devices.

In an embodiment, device information 452 for use with one or morepayment rules 454 may contain information regarding contextual factors.The contextual factors may include the information previously discussedregarding payment rules 454, such as location information, distanceinformation, time information, transaction item, and transaction amount.Additional contextual factors may include, for example, one or more ofthe current security state of the payment facilitating device (e.g.,trusted, untrusted, or unknown), the security state of the authorizingclient device, the security state of the one or more network connections401 from the payment application 412 providing payment credentials 402to POS module 420, said security state being trusted or untrusted (e.g.,based on detection of a Man in the Middle in the connection). In theembodiment, a decision to grant a request to proceed with the processingof the payment transaction may be based on such contextual informationand whether the contextual information conforms to one or more paymentrules 454. For example, the request could be granted based on one ormore rules related to contextual factors being met, such as: thedistance between the authorizing client device and the POS device doesnot exceed a threshold distance; the security state of the device is“trusted;” and the security state of the network is “trusted.”Similarly, the request could be denied when one or more rules related tocontextual factors are not met, such as: the distance between theauthorizing client device and the POS device exceeds a thresholddistance; the security state of the device is not “trusted;” and thesecurity state of the network is not “trusted.” In addition, variouscombinations of rules related to contextual factors may result indifferent outcomes regarding whether the request is granted. Forexample, even if the distance between the authorizing client device andthe POS device is within a threshold distance, the request may be deniedwhen the security state of the device is “untrusted.” Methods fordetermining whether to grant a request to process a payment transactionbased on contextual factors and payment rules are further illustratedwith regard to FIG. 6.

Disclosure regarding the security state of a device is further containedin U.S. application Ser. No. 14/634,115, entitled “ASSESSING A SECURITYSTATE OF A MOBILE COMMUNICATIONS DEVICE TO DETERMINE ACCESS TO SPECIFICTASKS,” filed on Feb. 27, 2015, and U.S. application Ser. No.15/687,395, entitled “METHODS AND SYSTEMS FOR BLOCKING THE INSTALLATIONOF AN APPLICATION TO IMPROVE THE FUNCTIONING OF A MOBILE COMMUNICATIONSDEVICE,” filed on Aug. 25, 2017, which are both incorporated byreference in their entirety. Disclosure regarding security states ofnetwork connections is further contained in U.S. application Ser. No.15/608,556, entitled “METHODS AND SYSTEMS FOR DETECTING AND PREVENTINGNETWORK CONNECTION COMPROMISE,” filed on May 30, 2017, which isincorporated by reference in its entirety. And disclosure regardingcontextual information, the security state of a device, and the securitystate of a connection is further contained in U.S. application Ser. No.14/071,366, entitled “METHODS AND SYSTEMS FOR SECURE NETWORKCONNECTIONS,” filed on Nov. 4, 2013, which is incorporated by referencein its entirety.

FIG. 6 is a flow diagram illustrating a method for authorizing a mobilepayment transaction according to an embodiment. The method illustratedin FIG. 6 can be carried out by at least some of the components in theexample electronic device(s) illustrated in FIG. 1 and FIG. 2, but canalso be carried out in environments other than those illustrated in FIG.1 and FIG. 2. According to an embodiment, the method 600 begins, inblock 602, when a request to authorize a payment transaction thatoriginates from a POS module is received. In an embodiment, a system forauthorizing a mobile payment transaction includes an anti-fraud service250 configured for receiving the request to authorize the paymenttransaction 204. According to an embodiment, the anti-fraud service 250can receive the request 204 from the payment processing service 240 whenit receives the request to process the payment transaction 203 from thePOS module 220.

The anti-fraud service 250 can be hosted by the payment processingserver 230 as is shown in FIG. 2. Alternatively, in another embodimentshown in FIG. 4, the anti-fraud service 450 can reside in another server432 communicatively coupled to the payment processing server 430 and/orto the POS module 420 over the network 401. In this embodiment, theanti-fraud service 450 can receive the request 404 over the network 401from the POS module 420 when the POS module 420 receives the paymentcredentials 402 from the facilitating mobile device 410. In anotherembodiment, the payment processing service 240, 440 and/or theanti-fraud service 250, 450 can be integrated in a common device withthe POS module 220, 420. In this case, the anti-fraud service 250, 450can receive the request to authorize 204, 404 via an internal link fromeither the payment processing service 240, 440 or the POS module 220,420.

In an embodiment, the request to authorize the payment transaction 204,404 can include the payment information 222, 422 of the paymenttransaction and information identifying the POS module 224, 424. Asstated above, the payment information 222 can include the paymentcredentials, e.g., 202, and information identifying the user 207 withwhich the payment credentials are associated. The informationidentifying the POS, e.g., 424, can include location information of thePOS module 424 a and/or information that can be used to determine thelocation information of the POS module 220, 420. For example, the POSidentifying information, e.g., 224, can include an identifier that canbe correlated to a location of the POS module 220. This correlation canbe included in a table that associates POS identifiers with locationsfor a plurality of POS modules, and the table can be stored in adatabase (not shown) on the payment processing server 230 or elsewhereon another server accessible via the network 201.

Referring again to FIG. 6, in block 604, when the request to authorizethe payment transaction 204, 404 is received by the anti-fraud servicecomponent (250, 450), an authorizing client device for the paymenttransaction is identified based on the payment information 222, 422.According to an embodiment, the authorizing client device, e.g., 210 a,is a personal mobile device associated with a user 207 that includes amobile payment application 212 a, and an anti-fraud client application214 which allows the anti-fraud service 250 to communicate with theauthorizing client device 210 a over the network 201. In an embodiment,for example, the authorizing client device 210 a can be a smartphone, atablet computer, or any network enabled handheld personal device.

In an embodiment, during a service registration phase, a user 207 candesignate one or more of her personal network enabled client devices tobe an authorizing client device 210 a for the user's mobile paymenttransactions. The user 207 can provide information relating to theclient device 210 a that enables the anti-fraud service 250 tocommunicate with the client device 210 a. For example, when theauthorizing client device 210 a is the user's mobile phone, the phonenumber associated with the phone can be provided. In another embodiment,the authorizing client device 210 a can be a dedicated client devicethat is provided to the user 207 upon registering with a serviceprovider associated with the anti-fraud service.

According to an embodiment, the anti-fraud service component 250, 450can store the information relating to the user's authorizing clientdevice(s) 252, 452 in a storage component coupled to the server 230, 432and accessed by the anti-fraud service component 250, 450. In anembodiment, when the request to authorize the payment transaction 204,404 is received, the anti-fraud service 250, 450 can be configured toextract the payment credentials 202, 402 of the user 207 from thepayment information 222, 422, in order to identify the user 207. Oncethe user 207 is identified, the anti-fraud service 250, 450 can beconfigured, in an embodiment, to identify the user's authorizing clientdevice 210 a by retrieving the information 252, 452 relating to theuser's authorizing client device(s).

Referring again to FIG. 6, in block 606, once the authorizing clientdevice for the payment transaction, e.g., 210 a, is identified, theanti-fraud service 250 determines context information associated withthe request. Contextual information associated with the request mayinclude contextual information associated with the authorizing clientdevice, the payment facilitating device, and the POS module. Forexample, the determined context information may include and of: thelocation information of the authorizing client device 210 a, locationinformation of the payment facilitating device, distance information,time information, transaction item, transaction amount, the securitystate of the payment facilitating device, the security state of theauthorizing client device, and the security state of the one or morenetwork connections 401 from the payment application 412 providingpayment credentials 402 to POS module 420.

As noted above, the information 252 relating to the user's authorizingclient device 210 a includes information that enables the anti-fraudservice 250 to communicate with the client device 210 a. Therefore,according to an embodiment, the anti-fraud service, e.g., 250, can usethe information 252 to generate and transmit a request for contextualinformation to the authorizing client device 210 a over the network 201,which in an embodiment, can be a Wi-Fi network, a LAN, a PAN, a WAN, aBLUETOOTH network, or a near field communication (NFC) depending on thecircumstances. In another embodiment when the authorizing client device210 a is a phone connected to a cellular network, the request message205 can be transmitted over the cellular network 201.

In another embodiment, the anti-fraud service 250 can transmit therequest for contextual information to the authorizing client device 210a indirectly via the POS module 220. In this case, when the POS module220 receives the request 205′, it can be configured to forward therequest 205′ to the authorizing client device 210 a over the network201, which in this embodiment, can be a wireless short range personalarea network (“WPAN”), such as a BLUETOOTH network or a NFC network.

When the request for contextual information is received by theauthorizing client device 210 a, the anti-fraud client application 214in the client device 210 a can provide its contextual information inseveral ways. For example, in an embodiment, when the client device 210a is equipped with a Global Positioning System (“GPS”) tracking unit,the device's contextual information, in this case location information,can be provided as geo-coordinates associated with its location.Alternatively or in addition, when the client device 210 a is connectedto a cellular network that includes a plurality of cell towers, thedevice's contextual information can also be provided as the location ofa cell tower nearest to the authorizing client device 210 a. Forexample, the nearest cell tower can be the destination tower thattransmits the request message 205 directly to the authorizing clientdevice 210 a. Alternatively or in addition, when the client device 210 ais connected to a wired or wireless network 201, the contextualinformation can be related to a wireless access point of the wirelessnetwork or related to a LAN.

According to an embodiment, the anti-fraud client application 214 in theclient device 210 a can be configured to generate a response 205 a tothe request for contextual information and to include the device'scontextual information in the response 205 a. The response 205 a canthen be returned to and received by the anti-fraud service 250 over thenetwork 201. In an embodiment, the anti-fraud service 250 can receivethe response 205 a directly from the client device 210 a over thenetwork 201, while in another embodiment, the anti-fraud service 250 canreceive the response 250 a′ indirectly via the POS module 220. In thelatter case, the response 205 a′ may not be received by the POS module220 when the authorizing client device 210 a is not located within themodule's short range WPAN 201. If, however, the client device 210 a islocated within the short range WPAN 201, the POS module 220 can beconfigured to receive and forward the response 205′ to the anti-fraudservice 250 over the network 201.

As discussed above, the anti-fraud service 250 can be configured totransmit the request for contextual information to the authorizingclient device 210 a over different network environments, e.g., a WAN anda WPAN. The response 205 a, 250 a′ from the authorizing client device210 a can be received over the same network environment as the one usedto transmit the request or over a different network environment fromthat used to transmit the request. Accordingly, in an embodiment, theanti-fraud service 250 can transmit the request to the client device 210a directly over a WAN, such as the Internet, and the response 205 a′ canbe received indirectly via the POS module 220 over a BLUETOOTH networkand a WAN.

Referring again to FIG. 6, in block 608, when the contextual informationof the authorizing client device is determined, the anti-fraud service250, 450 can be configured to compare the contextual information to oneor more applicable payment rules 454 to determine a disposition of therequest to authorize the payment transaction. According to anembodiment, the disposition of the request, i.e., whether the request204, 404 is granted, denied, or pending, can be determined based onwhether and to what degree the determined contextual informationsatisfies one or more applicable payment rules 454.

In an embodiment, the one or more applicable payment rules 454 may vary,e.g., based on the user of the authorized client device. In thisembodiment, payment rules 454 are determined to be applicable based onthose rules being associated with, e.g., a particular user, or aparticular authorizing client device. The association between thepayment rules and the user or client device may be created by, e.g., theuser or administrator of the authorizing client device. In thisembodiment, once applicable payment rules 454 are determined, requestsfor context information associated with block 606 may be fashioned basedon what contextual information must be satisfied by the applicablepayment rules 454 in order for the payment request to be granted, ordenied.

Any of the above embodiments may be used alone or together with oneanother in any combination. The one or more implementations encompassedwithin this specification may also include embodiments that are onlypartially mentioned or alluded to or are not mentioned or alluded to atall. Although various embodiments may have been motivated by variousdeficiencies with the prior art, which may be discussed or alluded to inone or more places in the specification, the embodiments do notnecessarily address any of these deficiencies. In other words, differentembodiments may address different deficiencies that may be discussed inthe specification. Some embodiments may only partially address somedeficiencies or just one deficiency that may be discussed in thespecification, and some embodiments may not address any of thesedeficiencies.

In addition, one will appreciate that in the description above andthroughout, numerous specific details are set forth in order to providea thorough understanding of the present invention. It will be evident,however, to one of ordinary skill in the art, that the present inventionmay be practiced without these specific details. In other instances,well-known structures and devices are shown in block diagram form tofacilitate explanation.

While one or more implementations have been described by way of exampleand in terms of the specific embodiments, it is to be understood thatone or more implementations are not limited to the disclosedembodiments. To the contrary, it is intended to cover variousmodifications and similar arrangements as would be apparent to thoseskilled in the art. Therefore, the scope of the appended claims shouldbe accorded the broadest interpretation so as to encompass all suchmodifications and similar arrangements.

What is claimed is:
 1. A method for processing a payment transaction,the method comprising: receiving, by a processor, a request to authorizean action from a point of sale device, the request including a firstcontext representing a first location associated with the action, and asecond context representing information about an account associated withthe action; determining a user device information associated with thesecond context representing information about the account associatedwith the action; transmitting a request for a third context to the userdevice associated with the second context representing information aboutthe account associated with the action, the third context including asecond location associated with the user device; receiving the thirdcontext including a second location associated with the user device fromthe user device; and determining whether to transmit a response to thepoint of sale device based on the comparison between the first contextrepresenting the first location associated with the action, and thethird context including the second location associated with the userdevice, the response representing whether to authorize the action. 2.The method of claim 1, wherein determining whether to transmit theresponse to the point of sale device based on the comparison between thefirst context, and the third context is based on comparing a geographicproximity between the first context and the third context.
 3. The methodof claim 2, further comprising transmitting a response to the point ofsale device indicating that the action is authorized.
 4. The method ofclaim 3, wherein the third context represents a temporal attribute ofthe point of sale device to the user device.
 5. The method of claim 1further comprising the account being associated with payment rules, thepayment rules representing one or more attributes that must be metbefore payment is authorized; and wherein the determination whether totransmit the response to the point of sale device based on thecomparison between the first context representing the first locationassociated with the action, and the third context including the secondlocation associated with the user device is based on the payment rulesassociated with the account.
 6. The method of claim 5, wherein thepayment rule is a plurality of rules and the one or more attributes tobe met before payment is authorized is based on a payment amount.
 7. Themethod of claim 6, wherein the payment rule includes one or moreattributes to be met before payment is authorized is based on theproximity between the point of sale device, and the user device.
 8. Asystem, comprising: at least one processor; and memory storinginstructions configured to instruct the at least one processor to:receive a request to authorize an action from a point of sale device,the request including a first context representing a first locationassociated with the action, and a second context representinginformation about an account associated with the action; determine auser device information associated with the second context representinginformation about the account associated with the action; transmit arequest for a third context to the user device associated with thesecond context representing information about the account associatedwith the action, the third context including a second locationassociated with the user device; receive the third context including asecond location associated with the user device from the user device;and determine whether to transmit a response to the point of sale devicebased on the comparison between the first context representing the firstlocation associated with the action, and the third context including thesecond location associated with the user device, the responserepresenting whether to authorize the action.
 9. The system of claim 8,wherein determining whether to transmit the response to the point ofsale device based on the comparison between the first context, and thethird context is based on comparing a geographic proximity between thefirst context and the third context.
 10. The system of claim 9, furthercomprising transmitting a response to the point of sale deviceindicating that the action is authorized.
 11. The system of claim 10,wherein the third context represents a temporal attribute of the pointof sale device to the user device.
 12. The system of claim 8 furthercomprising the account being associated with payment rules, the paymentrules representing one or more attributes that must be met beforepayment is authorized; and wherein the determination whether to transmitthe response to the point of sale device based on the comparison betweenthe first context representing the first location associated with theaction, and the third context including the second location associatedwith the user device is based on the payment rules associated with theaccount.
 13. The system of claim 12, wherein the payment rule is aplurality of rules and the one or more attributes to be met beforepayment is authorized is based on a payment amount.
 14. The system ofclaim 13, wherein the payment rule includes one or more attributes to bemet before payment is authorized is based on the proximity between thepoint of sale device, and the user device.
 15. A non-transitory storagemedium storing computer-readable instructions, which when executed,cause a computing device to: receive a request to authorize an actionfrom a point of sale device, the request including a first contextrepresenting a first location associated with the action, and a secondcontext representing information about an account associated with theaction; determine a user device information associated with the secondcontext representing information about the account associated with theaction; transmit a request for a third context to the user deviceassociated with the second context representing information about theaccount associated with the action, the third context including a secondlocation associated with the user device; receive the third contextincluding a second location associated with the user device from theuser device; and determine whether to transmit a response to the pointof sale device based on the comparison between the first contextrepresenting the first location associated with the action, and thethird context including the second location associated with the userdevice, the response representing whether to authorize the action. 16.The non-transitory storage medium of claim 15, wherein determiningwhether to transmit the response to the point of sale device based onthe comparison between the first context, and the third context is basedon comparing a geographic proximity between the first context and thethird context.
 17. The non-transitory storage medium of claim 16,further comprising transmitting a response to the point of sale deviceindicating that the action is authorized.
 18. The non-transitory storagemedium of claim 17, wherein the third context represents a temporalattribute of the point of sale device to the user device.
 19. Thenon-transitory storage medium of claim
 15. further comprising theaccount being associated with payment rules, the payment rulesrepresenting one or more attributes that must be met before payment isauthorized; and wherein the determination whether to transmit theresponse to the point of sale device based on the comparison between thefirst context representing the first location associated with theaction, and the third context including the second location associatedwith the user device is based on the payment rules associated with theaccount.
 20. The non-transitory storage medium of claim 19, wherein thepayment rule is a plurality of rules and the one or more attributes tobe met before payment is authorized is based on a payment amount. 21.The non-transitory storage medium of claim 20, wherein the payment ruleincludes one or more attributes to be met before payment is authorizedis based on the proximity between the point of sale device, and the userdevice.